1
2
Далі
Найпростішими словами, git pull робить git fetch, за яким слідує git merge.
Ви можете зробити git-вибір у будь-який час, щоб оновити свої гілки віддаленого відстеження в розділі refs / remotes / /.
Ця операція ніколи не змінює жодної вашої локальної гілки під посиланнями / керівниками, і це безпечно зробити, не змінюючи робочу копію. Я навіть чув про людей, які періодично запускають git fetch, виконуючи завдання cron у фоновому режимі (хоча я б не радив це робити).
Git pull - це те, що ви зробили б, щоб оновити локальну гілку з віддаленою версією, одночасно оновивши інші гілки віддаленого відстеження.
З документації Git для git pull:
У режимі за замовчуванням git pull - це скорочення для git fetch, за яким слідує git merge FETCH_HEAD.
|
Коли ви використовуєте pull, Git намагається автоматично виконати вашу роботу за вас. Він чутливий до контексту, тому Git об’єднає всі витягнуті коміти у гілку, в якій ви зараз працюєте. Pull автоматично об’єднує коміти, не дозволяючи спочатку переглядати їх. Якщо ви погано керуєте своїми відділеннями, у вас можуть траплятися часті конфлікти.
Коли ви отримуєте, Git збирає всі коміти з цільової гілки, які не існують у вашій поточній гілці, і зберігає їх у вашому локальному сховищі. Однак це не поєднує їх з поточною гілкою. Це особливо корисно, якщо вам потрібно постійно оновлювати сховище, але ви працюєте над тим, що може зламатися, якщо ви оновите файли.
Щоб інтегрувати коміти у вашу головну гілку, ви використовуєте злиття.
|
Важливо протиставити філософію дизайну git філософії більш традиційного інструменту управління джерелами, такого як SVN.
Subversion був розроблений та побудований за допомогою моделі клієнт / сервер. Існує єдине сховище, яке є сервером, і кілька клієнтів можуть отримати код із сервера, працювати над ним, а потім повернути його на сервер. Припущення полягає в тому, що клієнт завжди може зв’язатися з сервером, коли йому потрібно виконати операцію.
Git був розроблений для підтримки більш розподіленої моделі без потреби в центральному сховищі (хоча ви, звичайно, можете скористатися ним, якщо хочете). Також git був розроблений таким чином, що клієнту та "серверу" не потрібно бути одночасно в мережі. Git був розроблений таким чином, щоб люди за ненадійним посиланням могли обмінюватися кодом навіть по електронній пошті. Можна працювати повністю без зв'язку та записати компакт-диск для обміну кодом через git.
Для підтримки цієї моделі git підтримує локальне сховище з вашим кодом, а також додаткове локальне сховище, яке відображає стан віддаленого сховища. Зберігаючи локально копію віддаленого сховища, git може виявити необхідні зміни, навіть коли віддалене сховище недоступне. Пізніше, коли вам потрібно буде надіслати зміни комусь іншому, git може передати їх як набір змін з моменту часу, відомого віддаленому сховищу.
git fetch - це команда, яка говорить "оновити мою локальну копію віддаленого сховища".
git pull говорить "перенести зміни у віддаленому сховищі туди, де я зберігаю свій власний код".
Зазвичай git pull робить це, роблячи вибірку git, щоб оновити локальну копію віддаленого сховища, а потім об'єднати зміни у власне сховище коду і, можливо, у вашу робочу копію.
Зняти це слід пам’ятати, що на вашій робочій станції часто є принаймні три копії проекту. Одна копія - це власне сховище з власною історією комітів. Друга копія - це ваша робоча копія, де ви редагуєте та створюєте. Третя копія - це ваша локальна "кешована" копія віддаленого сховища.
|
Ось образ Олівера Стіла про те, як все це поєднується:
Якщо є достатній інтерес, я думаю, я міг би оновити зображення, щоб додати git clone та git merge ...
|
Одним із випадків використання git fetch є те, що наступне повідомляє вам про будь-які зміни у віддаленій гілці з моменту вашого останнього витягування ... так що ви можете перевірити, перш ніж виконувати фактичне витягування, яке може змінити файли у вашій поточній гілці та робочій копії.
git fetch
git diff ... походження
Дивіться: https://git-scm.com/docs/git-diff щодо синтаксису подвійних та потрійних крапок у команді diff
|
Мені трохи коштувало зрозуміти, в чому різниця, але це просте пояснення. master у вашому localhost - це філія.
Коли ви клонуєте сховище, ви отримуєте все сховище до свого локального хосту. Це означає, що на той момент у вас є вказівник початку / головки на HEAD і майстер, що вказує на ту саму HEAD.
коли ви починаєте працювати та виконуєте коміти, ви переносите головний покажчик на HEAD + ваші коміти. Але покажчик origin / master все ще вказує на те, що було, коли ви клонували.
Тож різниця буде такою:
Якщо ви зробите git fetch, він просто отримає всі зміни у віддаленому сховищі (GitHub) і перемістить вказівник origin / master на HEAD. Тим часом ваш місцевий керівник філії буде продовжувати вказувати, де він є.
Якщо ви зробите git pull, він в основному отримає (як пояснювалося раніше) та об’єднає будь-які нові зміни до вашогоголовна гілка та перемістіть вказівник на HEAD.
|
Іноді допомагає візуальне подання.
|
Коротко
git fetch схожий на pull, але не зливається. тобто він отримує віддалені оновлення (посилання та об’єкти), але ваш локальний файл залишається незмінним (тобто джерело / майстер оновлюється, але головний залишається незмінним).
git pull тягне вниз з пульта і миттєво зливається.
Більше
git clone клонує репо.
git rebase зберігає речі з вашої поточної гілки, які не є в гілці вище за течією, у тимчасову область. Тепер ваша гілка така ж, як і до того, як ви почали вносити зміни. Отже, git pull -rebase зніме віддалені зміни, перемотає вашу локальну гілку, відтворить ваші зміни по верхній частині вашої поточної гілки по черзі, поки ви не оновитесь.
Крім того, git branch -a покаже вам, що саме відбувається з усіма вашими гілками - локальними та віддаленими.
Ця публікація в блозі була корисною:
Різниця між git pull, git fetch та git clone (і git rebase) - Майк Пірс
і охоплює git pull, git fetch, git clone та git rebase.
====
ОНОВЛЕННЯ
Я думав оновити це, щоб показати, як ви насправді будете використовувати це на практиці.
Оновіть локальний репо з пульта (але не об’єднуйте):
git fetch
Завантаживши оновлення, давайте побачимо відмінності:
git diff master master / master
Якщо ви задоволені цими оновленнями, об’єднайте:
git pull
Примітки:
На кроці 2: Докладніше про різницю між локальним та віддаленим пультом дивіться: Як порівняти локальну гілку git з її віддаленою гілкою?
На кроці 3: Ймовірно, точніше (наприклад, при швидкозмінному репо) робити тут походження git rebase. Дивіться коментар @Justin Ohms в іншій відповіді.
Дивіться також: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
|
git-pull - Витягніть та злийте з іншим сховищем або локальною гілкою
КОНТРОЛЬ
git pull ...
ОПИС
Запускає git-fetch із заданими параметрами та викликає git-merge для об'єднання
витягнуто голову (-и) у поточну гілку. За допомогою --rebase викликає git-rebase
замість git-merge.
Зверніть увагу, що ви можете використовувати. (поточний каталог) як для витягування
з локального сховища - це корисно при об’єднанні локальних гілок
в поточну гілку.
Також зверніть увагу, що параметри, призначені для самого git-pull та основного git-merge
необхідно вказати перед параметрами, призначеними для git-fetch.
Якщо ви хочете, щоб історії були об’єднані, ви б витягнули, якщо б просто «хотіли codez», оскільки якась людина мітить тут деякі статті.
|
Ви можете отримати з віддаленого сховища, побачити відмінності, а потім витягнути або об’єднати.
Це приклад для віддаленого сховища з назвою origin та гілки з іменем master, що відстежує віддалене походження / master:
майстер перевірки git - -
git fetch
git diff походження / master
майстер походження git rebase -
|
Короткий і простий відповідь полягає в тому, що git pull - це просто git fetch, за яким слідує git merge.
Дуже важливо відзначити, що git pull автоматично об’єднається, подобається вам це чи ні. Звичайно, це може призвести до конфліктів злиття. Скажімо, ваш пульт є початковим, а ваша гілка - головним. Якщо ви git diff origin / master перед тим, як тягнути, ви мали б уявлення про потенційні конфлікти злиття та могли підготувати свою локальну гілку відповідно.
На додаток до витягування та натискання, деякі робочі процеси включають git rebase, наприклад, цей, який я перефразовую із пов'язаної статті:
git pull майстер походження -
git checkout foo-branch
git rebase master -
git push origin foo-branch
Якщо ви опинитеся в такій ситуації, у вас може виникнути спокуса git pull --rebase. Якщо ви насправді не знаєте, що робите, я б цього не радив. Це попередження зі сторінки користувача для git-pull, версія 2.3.5:
Це потенційно небезпечний режим роботи. Він переписує
історія, що не віщує нічого доброго, коли ви її опублікували
вже. Не використовуйте цю опцію, якщо ви не прочитали git-rebase (1)
обережно.
|
Гаразд, ось деяка інформація про git pull та git fetch, щоб ви могли зрозуміти фактичні відмінності ... кількома простими словами, fetch отримує найсвіжіші дані, але не змінює код і не збирається возитися з вашим поточним кодом локальної гілки , але витягніть отримані зміни коду та об'єднайте їх у свою локальну гілку, читайте далі, щоб отримати докладнішу інформацію про кожну:
git fetch
Він завантажить усі посилання та об’єкти та будь-які нові гілки до вашого локального сховища ...
Отримати гілки та / або теги (разом "посилання") від одного або декількох
інші сховища, поряд з об’єктами, необхідними для їх завершення
історії. Віддалене відстеження гілок оновлено (див. Опис
нижче щодо способів контролювати цю поведінку).
За замовчуванням будь-який тег, який вказує на історії, що витягуються, є
також принесений; ефект полягає в отриманні тегів, які вказують на гілки, які
Вас цікавить. Цю поведінку за замовчуванням можна змінити за допомогою
параметри --tags або --no-tags або шляхом налаштування
віддалений..tagOpt. Використовуючи refspec, який явно отримує теги,
Ви можете отримати теги, які не вказують на цікавлять вас гілки
в також.
git fetch може отримати забо одне іменоване сховище або URL-адреса, або
з декількох сховищ одночасно, якщо дано і є файл
пульти дистанційного керування. запис у файлі конфігурації. (Див. Git-config1).
Якщо не вказано пульт дистанційного керування, за замовчуванням початковим буде віддалений
використовується, якщо немає поточної гілки, налаштованої на поточну
відділення.
Імена посилань, які отримуються, разом з іменами об’єктів
вони вказують на, записуються в .git / FETCH_HEAD. Ця інформація може бути
використовується сценаріями або іншими командами git, такими як git-pull.
git pull
Він застосує зміни від віддаленої до поточної гілки в локальній ...
Включає зміни з віддаленого сховища в поточну гілку.
У режимі за замовчуванням git pull - це скорочення для git fetch, за яким слідує
git merge FETCH_HEAD.
Точніше, git pull запускає git fetch із заданими параметрами та
викликає git merge для злиття отриманих головок гілок у поточну
відділення. З --rebase він запускає git rebase замість git merge.
повинно бути ім'ям віддаленого сховища, переданому
git-fetch1. може назвати довільне віддалене посилання (наприклад,
назва тегу) або навіть колекція посилань з відповідними
віддалене відстеження гілок (наприклад, refs / heads /: refs / remotes / origin /),
але зазвичай це назва гілки у віддаленому сховищі.
Значення за замовчуванням для і читаються з
конфігурація "віддаленого" та "злиття" для поточної гілки, встановлена
git-branch --track.
Я також створюю візуал нижче, щоб показати вам, як git fetch та git pull працюють разом ...
|
Це інтерактивне графічне представлення дуже корисно для розуміння git: http://ndpsoftware.com/git-cheatsheet.html
git fetch просто "завантажує" зміни з віддаленого в місцеве сховище. git pull завантажує зміни та об’єднує їх у вашу поточну гілку. "У режимі за замовчуванням git pull - це скорочення для git fetch, за яким слідує git merge FETCH_HEAD."
|
Бонус:
Говорячи про pull & fetch у наведених вище відповідях, я хотів би поділитися цікавим трюком,
git pull --rebase
Ця команда вище є найкориснішою в моєму житті git, яка заощадила багато часу.
Перш ніж надсилати свої нові коміти на сервер, спробуйте цю команду, і вона автоматично синхронізує останні зміни сервера (з вибіркою + злиттям) і помістить ваш коміт у верхній частині журналу git. Не потрібно турбуватися про ручне витягування / об’єднання.
Детальнішу інформацію можна знайти на: http://gitolite.com/git-pull--rebase
|
Мені подобається мати візуальне уявлення про ситуацію, щоб зрозуміти ці речі. Можливо, інші розробники також хотіли б це побачити, тож ось моє доповнення. Я не повністю впевнений, що все це правильно, тому, будь ласка, коментуйте, якщо виявите помилки.
МІСЦЕВА СИСТЕМА
. ====================================================== ===
=================. ======================================== ===============
ВИДАЛЕНИЙ РЕПОЗИТОРІЙ. ДИСТАНЦІЙНИЙ РЕПОЗИТОРІЙ МІСЦЕВИЙ РЕПОЗИТОРІЙ РОБОЧА КОПІЯ
(ПОХОДЖЕННЯ). (В КЕШІ)
наприклад, . дзеркало
репозиторій github. . віддалене репо
Також може бути.
кілька репо.
.
.
FETCH * ------------------> *
Локальний кеш пульта дистанційного керування оновлюється джерелом (або декількома
зовнішні джерела, тобто розподілена природа git)
.
СКЛАД * ------------------------------------------------ --------> *
зміни об’єднуються безпосередньо у вашу локальну копію. коли виникають конфлікти,
вас просять прийняти рішення.
.
Здійснити. * <--------------- *
Отримуючи, наприклад, диверсію, ви можете подумати, що це коміт
оновить походження. У git коміт робиться лише у вашому локальному репо.
.
PUSH * <--------------------------------------- *
Синхронізує ваші зміни з початком.
Деякі основні переваги наявності дзеркала віддаленого пульта:
Ефективність (прокручуйте всі коміти та повідомлення, не намагаючись видавити їх по мережі)
Зворотній зв'язок про стан вашого місцевого репо (наприклад, я використовую SourceTree Atlassian, який дасть мені лампочку із зазначенням того, чи виконую я зобов'язання вперед чи позаду порівняно з початком. Цю інформацію можна оновити за допомогою GIT FETCH).
|
Я теж боровся з цим. Насправді я потрапив сюди із пошуком у Google саме того самого питання. Читаючи всі ці відповіді, нарешті, я намалював собі картину в голові, і я вирішив спробувати зрозуміти це, дивлячись на стан 2 сховищ та 1 пісочниці та дії, виконані з часом під час перегляду їх версії. Тож ось що я придумав. Будь ласка, виправте мене, якщо я десь зіпсував.
Три репо з вибором:
-------------------- ------------------------ ------ -----------------
- Віддалене репо - - Віддалене репо - - Віддалене репо -
- - - штовхається - - -
- @ R01 - - @ R02 - - @ R02 -
-------------------- ----------------------- ------ -----------------
--------------------- ----------------------------------------------
- Місцеве репо - - Місцеве репо - - Місцеве репо -
- тягнути - - - - дістати -
- @ R01 - - @ R01 - - @ R02 -
-------------------- ----------------------- ------ -----------------
-------------------- ----------------------- ------ -----------------
- Місцева пісочниця - - Місцева пісочниця - - Місцева пісочниця -
- Оформити замовлення - - виконано нову роботу - - -
- @ R01 - - @ R01 + - - @ R01 + -
-------------------- ----------------------- ------ -----------------
Три репо з витягом
-------------------- ----------------------- ------ -----------------
- Віддалене репо - - Віддалене репо - - Віддалене репо -
- - - штовхається - - -
- @ R01 - - @ R02 - - @ R02 -
-------------------- ----------------------- ------ -----------------
-------------------- ----------------------- ------ -----------------
- Місцеве репо - - Місцеве репо - - Місцеве репо -
- тягнути - - - - тягнути -
- @ R01 - - @ R01 - - @ R02 -
-------------------- ----------------------- ------ -----------------
-------------------- ----------------------- ------ -----------------
- Місцева пісочниця - - Місцева пісочниця - - Місцева пісочниця -
- Оформити замовлення - - виконано нову роботу - - об’єднано з R02 -
- @ R01 - - @ R01 + - - @ R02 + -
-------------------- ----------------------- ------ -----------------
Це допомогло мені зрозуміти, чому вибір є досить важливим.
|
Різницю між GIT Fetch та GIT Pull можна пояснити наступним сценарієм:
(Маючи на увазі, що фотографії говорять голосніше, ніж слова !, я подав зображення)
Візьмемо приклад того, що ви працюєте над проектом із членами вашої команди. Отже, буде одна головна гілка проекту, і всі учасники повинні розгалужити її до власного локального сховища, а потім попрацювати над цією локальною гілкою, щоб змінити / додати модулі, а потім повернутися до основної гілки.
Тому,
Початковий стан двох гілок, коли ви розгалужили основний проект у вашому локальному сховищі, буде таким - (A, B і C - це модулі, вже завершені проектом)
Тепер ви розпочали роботу над новим модулем (припустимо D), і після завершення модуля D ви хочете перенести його до основної гілки, але тим часом відбувається те, що один із ваших товаришів по команді розробив новий модуль E, F та модифікований C.
Отже, зараз сталося так, що вашому локальному сховищу не вистачає початкового прогресу проекту, і, отже, внесення ваших змін до основної гілки може призвести до конфлікту і може призвести до несправності вашого модуля D.
Щоб уникнути таких проблем і працювати паралельно з початковим прогресом проекту, є два шляхи:
1. Git Fetch - Це завантажить усі зміни, внесені до проекту початкової / основної гілки, які відсутні у вашому місцевому відділенні. І буде чекати, поки команда Git Merge застосує отримані зміни до вашого сховища або гілки.
Тож тепер Ви можете ретельно стежити за файлами перед тим, як об’єднати їх зі своїм сховищем. І ви також можете змінити D, якщо потрібно, через модифіковану C.
2. Git Pull - Це оновить вашу локальну гілку з початковою / основною гілкою, тобто насправді те, що вона робить, це комбінація Git Fetch та Git злиття одна за одною.
Але це може спричинити конфлікти, тому рекомендується використовувати Git Pull із чистою копією.
|
Ми просто говоримо:
git pull == git fetch + git merge
Якщо ви запускаєте git pull, вам не потрібно об'єднувати дані з локальними. Якщо ви запускаєте git fetch, це означає, що ви повинні запустити git merge для отримання останнього коду на локальну машину. В іншому випадку локальний машинний код не буде змінено без злиття.
Отже, у Git Gui, коли ви виконуєте вибір, ви повинні об’єднати дані. Fetch сам не вносить зміни в код у вашому локальному. Ви можете це перевірити, коли оновлюєте код, завантажуючи
одного разу дістати і побачити; код, який він не змінить. Потім ви зливаєте ... Ви побачите змінений код.
|
git fetch витягує код із віддаленого сервера до ваших гілок відстеження у вашому локальному сховищі. Якщо ваш пульт має ім'я origin (за замовчуванням), тоді ці гілки будуть знаходитись у origin /, наприклад origin / master, origin / mybranch-123 тощо. Це не ваші поточні гілки, це локальні копії цих гілок із сервера .
git pull робить отримання git, але потім також об'єднує код з гілки відстеження у ваш поточнийлокальна версія цієї гілки. Якщо ви ще не готові до цих змін, просто спочатку git fetch.
|
git fetch отримає віддалені гілки, щоб ви могли git diff або git об'єднати їх з поточною гілкою. git pull запустить вибірку на віддаленому сегменті, відстежуваному поточною гілкою, а потім об'єднає результат. Ви можете використовувати git fetch, щоб перевірити, чи є оновлення для віддаленої гілки, без необхідного об’єднання їх з вашою локальною гілкою.
|
Git Fetch
Ви завантажуєте зміни до своєї локальної гілки з початкового рівня через fetch. Fetch запитує віддалене репо для всіх комітів, зроблених іншими, але у вас немає у вашому локальному репо. Fetch завантажує ці коміти та додає їх до локального сховища.
Git Merge
Ви можете застосувати зміни, завантажені за допомогою команди злиття. Злиття бере коміти, отримані із завантаження, і намагається додати їх до вашої локальної гілки. Злиття збереже історію комітів ваших локальних змін, щоб, коли ви ділитеся гілкою з push, Git знав, як інші можуть об'єднати ваші зміни.
Git Pull
Витяг та злиття виконуються досить часто, щоб була створена команда, яка поєднує ці два, витягнути. Pull виконує вибірку, а потім об'єднання, щоб додати завантажені коміти до вашої локальної гілки.
|
Говорячи простими словами, якщо ви збиралися вскочити на літак без будь-якого підключення до Інтернету ... перед вильотом ви могли б просто зробити git fetch origin . Він отримає всі зміни у вашому комп’ютері, але тримайте його окремо від вашої локальної розробки / робочої області.
У літаку ви можете внести зміни у свою локальну робочу область, а потім об’єднати її з отриманим та вирішити потенційні конфлікти об’єднання без підключення до Інтернету. І якщо хтось не вніс нові зміни до віддаленого сховища, тоді як тільки ви прибудете до пункту призначення, ви зробите git push origin і підете за кавою.
З цього чудового підручника Atlassian:
Команда git fetch завантажує коміти, файли та посилання з
віддаленого сховища до вашого локального сховища.
Витягування - це те, що ви робите, коли хочете побачити те, що є у всіх інших
працював над. Це схоже на оновлення SVN тим, що дозволяє бачити
як прогресувала центральна історія, але це вас не змушує
фактично об’єднати зміни у ваш репозиторій. Git ізоляти
отриманий вміст як із існуючого локального вмісту, він абсолютно
ніякого впливу на вашу роботу з місцевого розвитку. Отриманий вміст має бути явно перевірений за допомогою команди git checkout. Це робить
отримання безпечного способу перегляду комітів перед їх інтеграцією
у вашому локальному сховищі.
При завантаженні вмісту з віддаленого сховища для виконання завдання доступні команди git pull та git fetch. Можна розглянути
git отримати "безпечну" версію двох команд. Він завантажиться
віддалений вміст, але не оновлювати робочий стан локального сховища,
залишаючи свою поточну роботу цілою. git pull є більш агресивним
Крім того, він завантажить віддалений вміст для активного локального
і негайно виконайте git merge, щоб створити коміт злиття
для нового віддаленого вмісту. Якщо у вас є зміни, які очікують на розгляд
це спричинить конфлікти та призведе до вирішення конфлікту злиттям
потік.
З git pull:
Ви не отримаєте жодної ізоляції.
Це не потрібно чітко перевіряти. Тому що це неявно робить злиття git.
Крок об’єднання вплине на ваш місцевий розвиток і може спричинити конфлікти
Це в основному НЕ безпечно. Це агресивно.
На відміну від git fetch, де це впливає лише на ваші .git / refs / remotes, git pull впливатиме як на ваші .git / refs / remotes, так і на .git / refs / heads /
Гммм ... тож якщо я не оновлюю робочу копію за допомогою git fetch, то де я вношу зміни? Де Git fetch зберігає нові коміти?
Чудове запитання. Це ставить його десь ізольовано від вашої робочої копії. Але знову куди? Давай дізнаємось.
У каталозі вашого проекту (тобто там, де ви виконуєте свої команди git) виконайте:
ls. Це покаже файли та каталоги. Нічого крутого, я знаю.
Тепер зробіть ls -a. Це покаже крапкові файли, тобто файли, що починаються з. Тоді ви зможете побачити каталог із назвою: .git.
Зробіть cd .git. Це, очевидно, змінить ваш каталог.
Тепер настає найцікавіша частина; робити ls. Ви побачите список каталогів. Ми шукаємо посилання. Зробіть посилання на компакт-диск.
Цікаво подивитися, що знаходиться всередині всіх каталогів, але зупинимось на двох з них. голови та пульти. Використовуйте cd, щоб перевірити їх усередині.
Будь-яке вибране вами git буде оновлювати елементи в каталозі /.git/refs/remotes. Він не буде нічого оновлювати в каталозі /.git/refs/heads.
Будь-яке git pull спочатку виконує git-вибірку, оновлює елементи в каталозі /.git/refs/remotes, потім об’єднується з вашим локальним, а потім змінює головку всередині каталогу /.git/refs/heads.
Дуже хорошу відповідь на це питання можна знайти також у розділі Де розміщується "git fetch" ?.
Крім того, знайдіть "позначення косою рисою" у дописі про конвенції про іменування гілок Git. Це допоможе вам краще зрозуміти, як Git розміщує речірізні каталоги.
Щоб побачити фактичну різницю
Просто зробіть:
майстер походження git fetch -
майстер перевірки git - -
Якщо віддалений майстер був оновлений, ви отримаєте таке повідомлення:
Ваша гілка відстає від 'origin / master' на 2 коміти, і її можна перемотувати вперед.
(використовуйте "git pull", щоб оновити вашу локальну гілку)
Якби ви не отримали і просто зробили майстер перевірки git, тоді ваш локальний git не знав би, що додано 2 коміти. І це просто сказало б:
Уже на "майстер"
Ваша гілка оновлена з позначкою "origin / master".
Але це застаріло і неправильно. Це тому, що git дасть вам відгук виключно на основі того, що він знає. Він не звертає уваги на нові коміти, які ще не виконував ...
Чи є спосіб побачити нові зміни, внесені в віддаленому режимі під час роботи на гілці локально?
Деякі IDE (наприклад, Xcode) надзвичайно розумні і використовують результат отримання git і можуть анотувати рядки коду, які були змінені у віддаленій гілці вашої поточної робочої гілки. Якщо цей рядок був змінений як локальними змінами, так і віддаленою гілкою, тоді цей рядок буде позначено червоним. Це не конфлікт об’єднання. Це потенційний конфлікт об’єднання. Це хед-ап, який ви можете використовувати для вирішення майбутнього конфлікту злиття, перш ніж робити git pull з віддаленої гілки.
Порада:
Якщо ви отримали віддалену гілку, наприклад зробив:
git fetch origin feature / 123
Тоді це перейде у ваш каталог віддаленого керування. Він все ще недоступний у вашому локальному каталозі. Однак це спрощує замовлення до цієї віддаленої гілки DWIM (робіть те, що я маю на увазі):
функція git checkout / 123
Вам більше не потрібно робити:
git checkout -b особливість / 123 походження / особливість / 123
Більше про це читайте тут
|
Єдина різниця між git pull та git fetch полягає в тому, що:
git pull витягує віддалену гілку та об'єднує її.
git fetch отримує лише віддалену гілку, але вона не зливається
тобто git pull = git fetch + git merge ...
|
Git дозволяє хронологічно застосовувати старі коміти після нових комітів.
Через це акт передачі комітів між сховищами ділиться на два етапи:
Копіювання нових комітів з віддаленої гілки для копіювання цієї віддаленої гілки всередині локального репо.
(репо до операції репо) master @ remote >> remote / origin / master @ local
Інтеграція нових комітів до місцевого відділення
(операція всередині репо) віддалений / джерело / майстер @ локальний >> майстер @ локальний
Існує два способи зробити крок 2. Ви можете:
Виділіть локальну гілку після останнього спільного предка та додайте нові коміти паралельно комітам, які є унікальними для локального сховища, що завершується об’єднанням коміту, закриваючи форк.
Вставте нові коміти після останнього спільного предка та повторно застосуйте коміти, унікальні для локального сховища.
У термінології git кроком 1 є git fetch, кроком 2 є git merge або git rebase
git pull - це git fetch та git merge
|
Git отримує гілку останньої версії від віддаленого до локального за допомогою двох команд:
git fetch: Git збирається отримати останню версію з віддаленого на локальний, але він не зливається автоматично.
майстер походження git fetch -
git log -p master..origin / master
git merge origin / master
Наведені вище команди означають, що завантажують останню версію основної гілки від джерела до віддаленої до гілки головного джерела. А потім порівнює місцеву головну гілку та головну гілку. Нарешті, об’єднайте.
git pull: Git збирається отримати останню версію з пульта дистанційного керування та об’єднатись у локальну.
git pull майстер походження -
Наведена вище команда еквівалентна git fetch та git merge. На практиці git fetch може бути більш безпечним, оскільки перед об’єднанням ми можемо побачити зміни та вирішити, чи об’єднувати.
|
У чому різниця між git pull та git fetch?
Щоб зрозуміти це, спочатку потрібно зрозуміти, що ваш локальний git підтримує не тільки ваше локальне сховище, але він також зберігає локальну копію віддаленого сховища.
git fetch оновлює вашу локальну копію віддаленого сховища. Наприклад, якщо вашим віддаленим сховищем є GitHub - ви можете захотіти отримати будь-які зміни, зроблені у віддаленому сховищі, у свою локальну копію віддаленого сховища. Це дозволить вам виконувати такі операції, як порівняння або об'єднання.
git pull, з іншого боку, призведе до зменшення змін у віддаленому сховищі, де ви зберігаєте власний код. Як правило, git pull спочатку робить вибір git, щоб оновити локальну копію віддаленого сховища, а потім об’єднає зміни у власне сховище коду і, можливо, у вашу робочу копію.
|
git pull == (git fetch + git merge)
git fetch не змінюється на локальні гілки.
Якщо у вас вже є локальне сховище з пультом дистанційного керування, налаштованим для бажаного проекту, ви можете захопити всі гілки та теги для існуючого пульта за допомогою git fetch. ... Fetch не вносить жодних змін у локальні гілки, тому вам потрібно об’єднати віддалену гілку з парною локальною гілкою, щоб включити нещодавно отримані зміни. з github
|
Просте графічне представлення для початківців,
ось,
git pull
отримає кодз репозиторію та перебазувати з вашим локальним ... у git pull існує можливість створення нових комітів.
але в,
git fetch
отримає код із сховища, і нам потрібно перебазувати його вручну за допомогою git rebase
наприклад: я збираюся отримати з майстра сервера та перебазувати його у своєму локальному майстрі.
1) git pull (перебазування буде зроблено автоматично):
git pull майстер походження -
тут origin - це ваш віддалений майстер репо - ваша гілка
2) git fetch (потрібно перебазувати вручну):
майстер походження git fetch -
він буде отримувати зміни сервера на початку. і він буде знаходитися у вашому локальному, поки ви не перебазуєте його самостійно. нам потрібно виправляти конфлікти вручну, перевіряючи коди.
git rebase origin / master
це перебазує код у локальний. перед цим переконайтеся, що ви в правій гілці.
|
Намагаємося бути зрозумілими та простими.
Команда git pull насправді є ярликом для git fetch, за яким слідує git merge або команда git rebase, залежно від вашої конфігурації. Ви можете налаштувати свій репозиторій Git так, щоб git pull був вибором, за яким слідує перебаза.
|
Насправді Git зберігає копію власного коду та
віддаленого сховища.
Команда git fetch оновлює вашу локальну копію, отримуючи дані з віддаленого сховища. Причина, по якій нам це потрібно, полягає в тому, що хтось інший міг внести деякі зміни в код, і ви хочете тримати себе в курсі подій.
Команда git pull приносить зміни у віддаленому сховищі туди, де ви зберігаєте власний код. Зазвичай git pull робить це, виконуючи спочатку «вибір git», щоб оновити локальну копію віддаленого сховища, а потім об’єднує зміни у власне сховище коду та, можливо, у вашу робочу копію.
|
1
2
Далі
Високоактивне запитання. Заробіть 10 репутації, щоб відповісти на це питання. Вимога про репутацію допомагає захистити це питання від спаму та відсутності відповідей.
Не відповідь, яку ви шукаєте? Перегляньте інші запитання, позначені тегом git-control version git-pull git-fetch, або задайте власне запитання.